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METHOD AND SYSTEM FOR MULTIMEDIA MESSAGING SERVICE 



BACKGROUND OF THE INVENTION 

The invention relates generally to wireless communications teclinology, 
and more particularly to method and system for multimedia messaging 
service. 

Mobile terminals such as mobile phones have become a popular 
means to communicate with other people. Many sen/ices are now available 
on mobile terminals. One of the popular services is the mobile multimedia 
service (MMS), which includes images, voice, and audio and video contents. 
This service will enrich person-to-person messaging and pave the way for 
content-push services. With more and more rich media enabled mobile 
terminals and network architectures available, on-demand mobile 
multimedia services will be delivered to users via media streaming and 
downloading techniques that enrich mobile browsing and content 
accessing. 

Multimedia-enriched services are expected to drive usages, operator 
revenues and bandwidth consumptions in mobile networks. However, at 
present, rich media messages are too large for mobile terminals with 
relatively small user space (typically 2M bytes) to store locally. For example, 
a two minute MPEG-4 encoded QCIF (Quarter Common Intermediate 
Format) .video pjqyed qt 10 frames per second (fps) will take roughly 1.5M 
bytes space. This is unacceptable to most mobile phones in the market 
because of their small storage space that is shared by different applications. 
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FIG. 1 shows a MMS reference architecture 10 as defined by 3GPP 
(Third Generation Partnership Project), which is an organization that develops 
specifications for a 3G systenn. In FIG. 1 , a MMS relay/sen/er 20 is connected 
to various elements, including a billing system 32, MMS VAS (value added 
service) applications 34, MMS user databases 36, a HLR (home location 
register) 38, and a plurality of external servers 42 to 48 for providing 
functionalities such as E-mail, fax, SMS, etc. Server 48 is a media server that 
stores rich-media contents including video. Alternatively, server 48 may be 
located in MMS relay/server 20 or may be a web sen/er. MMS relay/server 20 
is also connected to a "foreign" MMS relay/server 40, which is located in 
another MMSE (Multimedia Message Service Environment). A MMSE refers to 
a collection of MMS specific network elements under the control of a single 
administration and may include more than one MMS relay/server. MMS user 
agents A, B and C can send multimedia messages to one another via the 
MMS relays/sen/ers. A MMS user agent refers to an application residing on a 
mobile terminal (e.g., a user equipment (UE), a mobile station (MS), etc.) or 
an external device that performs MMS-specific operations on a user's behalf. 

FIG. 2 is a flowchart diagram of a multimedia message (MM) delivery 
process 100. It Illustrates how a multimedia message is delivered via 
streaming in a conventional way. Upon receiving a MMS message 
notification, the MMS user agent will notify the user of an associated mobile 
terminal that a new MM has arrived (step 102). If the user chooses to view 
the MM (step 106), the attachment associated with the MM is parsed (step 
112) to determine whether a SDP (Session Description Protocol) file is 
attached (step 116). A SDP file contains the description of the session 
(including session name, author, etc.), the type of media to be presented, 
and the bit rate of the media. If a SDP file is not attached, it may be 
because the MM contains non-streomable contents such as messages with 
plain text only. In such a case, the MMS user agent will render the MM 
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immediately. On the other hand, if a SDP file is attached, it WiW be parsed 
(step 122). With the parameters from the SDP file, the MMS user agent can 
connect the mobile terminal to the media server via RTF (Transport Protocol 
for Real-Time Applications)/RTSP(Real Time Streaming Protocol) protocols 
(step 126) and receive the contents from the media server via streaming 
(step 132). At the same time, the MMS user agent can render the MM (step 
136). 

However, live streaming from a media server in a wireless environment 
will take considerable amount of time about 8 to 15 seconds for each two 
minute MPEG-4 QCIF video message. For a larger video message, the user 
will have to view it in discrete segments because the user has to wait for 8 to 
15 seconds for each two minute video segment to arrive. Given the 
experience of video streaming on the Internet, which usually requires an 
initial waiting time of 6 to 15 seconds for each video message, regardless of 
the size of the video message, the delays in a wireless environment will be 
unacceptably longer and will make the user to wait annoyingly. 

Therefore, there is a need for a MMS system that significantly improves 
a user's experience associated with receiving and vievsrfng MMs. 

SUMMARY OF THE INVENTION 

The present invention allows a portion of a multimedia message, 
usually the beginning part of the message (e.g., the first 10 seconds of the 
message) to be delivered to and stored on a mobile terminal beforehand. 
For example, a 10 seconds MPEG-4 encoded QCIF video occupies roughly 
8P'-120k space, which is much less than the capacity required for-storing the 
whole message. When a user wants to view the message, the portion of the 
message stored locally will be played back immediately, while at the same 
time a user agent residing in the mobile terminal will contact a media server 
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for the remaining contents using the streaming technology. This would give 
the user an impression that the whole message is stored locally since there is 
nearly no noticeable delay in the playback, thus providing a much better 
user experience. The partial contents downloaded can be a portion of the 
whole multimedia message, or an unrelated rich-media message provided 
by a third party as an advertisement. In this way, the usage of the local 
storage space on the mobile terminal will be much more efficient. 

Other objects and attainments together with a fuller understanding of 
the invention will become apparent and appreciated by referring to the 
following description and claims taken in conjunction with the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is explained in further detail, and by way of example, 
with reference to the accompanying drawings wherein: 

FIG. 1 shows a MMS reference architecture as defined by 3GPP; 

FIG. 2 is a flowchart diagram of a conventional multimedia message 
delivery process; 

FIG. 3 is a flowchart diagram illustrating a process performed by a MMS 
user agent in connection with receiving and delivering multimedia messages 
according to a first embodiment of the invention; and 

FIG. 4 is d flowchart diagram illuistratirig a multimedia message 
delivering process performed by a MMS server according to a second 
embodiment of the invention. 
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Throughout the drawings, the same reference nunnerals indicate sinnilar 
or corresponding features or functions. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention allows a portion of a multimedia message (MM), 
usually the beginning part of the message (e.g., the first 10 seconds of the 
message), to be delivered to a mobile terminal or user equipment (UE) in 
advance. For example, a 10 seconds MPEG-4 encoded QCIF video will 
occupy roughly 80-1 20k space, which is much less than the capacity 
required for storing the whole message. When a user wants to view the MM, 
the portion of the message stored locally will be played back immediately, 
while at the same time the user agent residing in the UE will contact the 
media server for the remaining contents using the streaming technology 
defined in the 3GPP standard specification. This would give the user on 
impression that the whole message is stored locally since there is nearly no 
noticeable delay in the playback, thus providing a much better user 
experience. The partial contents downloaded in advance can be a portion 
of the whole multimedia message, or an unrelated rich-media message 
provided by a third party as an advertisement. 

FIG. 3 is a flowchart diagram illustrating a process 200 performed by o 
MMS user agent residing in a mobile terminal, in connection with receiving 
and delivering MMs according to a first embodiment of the invention. As 
illustrated, after the user agent receives a MMS message notification {step 
202), it will try to parse the attachment to the message notification (step 206) 
to determine whether a SDP file is attached (step 212). As described before, 
the. SDP file contains the description oi the session (e.g., session name, 
author, etc.), the type of the media to be presented and the bit rate of the 
media. If no SDP file is attached because for example, the MM contains 
non-streamable contents such as text messages only, the user agent will 
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notify the user of the newly arrived MM (step 220) and allow the user to have 
an option to view the message. 

However, if a SDP file is attached and the user agent recognizes that a 
link to rich media contents is included in the SDP file after parsing the SDP file 
(step 214), it will try to immediately download, from the media server, a part 
of the message for a predetermined duration, e.g., 15 seconds, using the RTP 
protocols (step 222). The user agent may also determine how long the 
portion of the MM should be pre-fetched by consulting vsiith a database in 
the mobile terminal that contains information about the network 
characteristics, mobile terminal capability and user preferences. Then, a 
determination of whether the download is successful is made (step 232). If 
the download fails due to, for instance, problems relating to the networic or 
media server, the user agent will notify the user about the newly arrived MM 
(step 220) and deliver the message in a conventional way such as illustrated 
in FIG. 2. 

On the other hand, if the download is successful and upon receiving 
the portion of the MM, e.g., 15 seconds of the MM, the user agent will save 
that received portion locally and modify the SDP file for later use, noting the 
size of the contents stored locally, where to fetch the remaining portion of 
the contents, the size of the remaining portion, etc. (step 236). Then the user 
agent notifies the user that a new MM has just arrived (step 220). If the user 
wants to view the MM, the user agent will quickly ploy back the received 
portion, while at the same time it will try to set up a streaming connection 
with media server in a conventional manner for the remaining contents of 
the MM. Under most circumstances, there is a sufficient time to set up the 
connection with the.media server during that period of time in which the 
received portion of the MM is being played, so that the remaining contents 
of the MM will become available for the user to view in a seamless manner. 
In this way, the user will have a quick access to the MM, eliminating the 
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waiting time ranging from 8 to 15 seconds otherwise required for tine user to 
start viewing ttie MM. The invention also gives the user an innpression of 
viewing the MM locally, and thus easing the impatience of a typical user. If 
the user finds the contents being played are not interesting, he or she may 
immediately interrupt the connection without further wasting the time. 

FIG. 4 is a flowchart diagram illustrating a MM delivering process 300 
performed by a MMS server (e.g., in MMS relay/server 20) according to a 
second embodiment of the invention. Upon receiving a MM (step 302), the 
MMS server will determine whether it contains rich media contents (step 306). 
If it contains text only, the server will deliver the message directly to the UE 
without any modification so as to make it immediately available to the user 
(step 310). OthenA/ise, the server will need to modify the message. The server 
will first store the message with rich media contents in a pre-selected 
location, e.g., a media server (step 312), and copy a portion of the message, 
e.g., the first 15 seconds (step 316). The server then creates a SDP file that 
contains the location of the message, the duration of the copied portion of 
the message, and other information (step 326). Thereafter, the sen^^er 
attaches the SDP file to the copied portion of the original message to create 
a new MM (step 332). Alternatively, the server may also attach the SDP file to 
a third party's contents, such as advertisements. The newly created MM will 
be sent to the user agent (step 31 0). 

Upon receiving the new MM from the MMS server, the user agent will 
save it in the same way as any downloaded message. When the user tries to 
view the message, the user agent will first play back the locally stored 
contents, while at the some time it will try to set up a streaming connection 
with the media server using the information provided by the attached SDP 
file. This will allow the remaining contents of the message to be available to 
the user to view in a seamless way. In this way, a much higher efficiency in 
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the usage of the local storage space on the mobile terminal can be 
achieved. 

As described above, the partially downloaded contents received by 
the user agent can be a portion of the original MM, or an unrelated rich 
media message provided by a third party as an advertisement. In the latter 
cose, the third party may allow the user to access the MM at no charge if 
the user commits to view the attached advertisement in its entirety. In a 
similar manner, multiple MMs can link to the same locally stored contents, 
e.g., the same advertisement. 

While the invention has been described in conjunction with specific 
embodiments, it is evident that many alternatives, modifications and 
variations will be apparent to those skilled in the art in light of the foregoing 
description. Accordingly, it is intended to embrace all such alternatives, 
modifications and variations as fall within the spirit and scope of the 
appended claims. 
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